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Abstract 
AS amateur packet radia software 
becomes more comp | icated and software 


env i ronments i mprove>, the use 
become more 


deve | omen t 
of hishlevel jlansuades will 
favourable, A design approach for 
protocol software basedo n modules and 
Finite State Mechinesis described», which 
formalises the interfaceto I0 devices, 
and extends the use of the protocol 75 
State Machine model into the 
implementation stage. Its adoption should 
m3keimplementstion5d of Level 2 and 3 
protocols auickers easier and more 
understandsble. 


Introduction 


Traditionaliys communicst ion software 
for microprocessors wa3s wri tten in the 
native assembiylansusde,for two reasons) 
the simple microprocessor architectures 
| imited the code comelexityy size and 
speed, and the environment needed for 
software deve lopment at 3a higher level was 
not available. The early Termi n3 1 Node 


Control ters were implemented under’ these 
restrictions. 

The first obJection {5s no fonger 
valid. The explosion of the Personal 


computer has made significant processing 
Power cheap and readily available, and 
many of these machines canbteusedfor 
both software development and 3s 3 
ded i cated or shared host. 


Secondly» software tools and 
environments have grown into3 rich and 


Plentiful agrenat o develop softwarein. 
Compilers, interpreter9 simulations» 
graphics, databases and communications 


softwareo f surprising complexity and 
usefulness 3re now 3V3/ |latle for even the 
simplest of microprocessors. 


Frotoco!lsof tware developers should 
consider adorpting high level languages 
(such as Fascal and C) for their 


communications systems. The advantages of 
expressing softwarein 3 structured, high 
level lenduade are well known (see any 
Software Engineering text). 


Once ~@ah ishtevellanduage has been 
chosen + some important design 
cond i derations must be faced. The 
festureso f the chosen /anduase must be 
exploited to improve the software design, 
implementation and maintenance. Fut more 
Senerally,st he problemmay be wor ded a5 
3 auestion*s how should 3 communications 


Program be designed? A design arprproach 
which answers this question will be 
discussed. 


Dats Abstract i an 


Al | software for driving devices (ie, 
ports) shauldbemodularised. High level 
languages offer mechanisms for success i ve 
abstract ion or modulsrisstion, usuallyin 
the form of procedures/ functions or 
subroutines. A desidn aprproachenforces 
the decomposition of sof tware i nto modu | es 
in a discipline4 way. 


Modularisation allows for the 
implementationofwell defined interfaces 
to entire functionally-~inderendent 
components of 3 software system. Amodule 
(within 8) program) is one or_- more 
sub-programs which Perform 3. specified 
task on some dat3. The module 
encapsulstes both the dats obJect, 3nd 
the sub-programs which mani pulateit, All 
aspectso f the modute are comp i ete lY 
defined by the Programmers in an 
appropriate notation. 


Def inition of 3 Module 


dr3wn from packet 
radio software is shown below. Modules 
are def ined for 3 serial port (ie. 3 
UART) » and @ “packet_report” (Cie. the 
software interface to 3 Protocol 
control ler chip), 


An example 


These definitions are presentedin 
@Fascal-like p5eudocOde, 2 form which 
has been successfully usedbyt h e  guthor. 
The Purpose of the no-tat ion is to convey 
semantic specification» rather than 
syntactic detail. 
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serial_port: 
C€global data3 
resisters: 
begin 
TXbuff, RXbuff, DivisorL SB, 
LivisorMSBy Intret,s LineControl, 
L ineStat» ModemControl » 
ModemStat:UART Registers 
end 
{orerators 3 
procedure initial ise; 
procedure send char (chichar) ? 
function char_receivedtboolesan? 
function get _rece i ved,char tchar 3 
end (serial_port3; 


Packet_port: 
Cglobal data} 
bufferstarrayll..nijo f 
resisters: 
begin 
TXbuffs RXbuff, Intrets LineControl, 
LineStat » ModemControl +» ModemStat 
tFrotocal_Controller Register: 
end 
{operators 3 
procedure initi3lise; 
procedure send_frame(bibuffer) : 
procedure | isten (bibuffer) § 
function frame_receivediboolean: 
procedure get_received_frame ( 
var bibuffer) 3 


buffer_types 


end {packet_port}; 


Once the module (port interface) has 
been specified 35 t h e examples show, 
imp lementat i on of the module can _ Proceed 
by further ref ining the data obJectss and 
ty writing the interface procedures or 
function code. If necessary » the module 
specification can be modified slightly In 
the light of implementation 
cons i derat i onst but th i s shou Id be avo i ded 
since it implies weakness in the orisginal 
module srecification. 


Once implemented,» using t h e module 
should be a simple case of making calls to 
the interface procedures or functions 3s 
reauired. Since languages such as Pasca! 
and C do not support modules explicitly, 
it is the programmer’s responsibility to 
enforce correct use of the module in 
his or her code »bty using the defined 
interface5 only. For instance,» when using 
2 Packet-port module, there must be no 
reading or writing of any of the data 
variables, or the port device itself. 


The advantages) and 4i sadvan tages of 


using this organisationo § f device 
interface software will be discussed 
later. 
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Control Abstraction 

Communication systems are usual fy 
“event driven”; the software must respond 
to asynchronous events: such as an 
operator keyed commandyor areceived 
Packet. Such software must decide on 
appropriate processing of events on the 
basis of the historyy,or stateof the 
system. A form3 | mode | which is 
applicable in such systems is’ the Finite 
State Mach i ne. 


A Finite State Machine (FSM) consists 
of a finite set of states, each of which 
knows of a set of events, and 3 transition 
function which maps (state,» event) into 
(new-state,s action), The action is 2a 
member of 3 set of actions, wh ich’ express 
interaction or modification of the FSM’s 
environment. 


FSMs are easily depicted in 
diagrammatic form. The states are 
represented ty circles, transit i ons 
between states by directed arcs, and 
events 3nd actiond5 by “event : act i on” 
labels o n the transitions. Fart of the 


FSM model of AX25 [Fox 843 is presented 
in Figure i. It shows the states which 
are passed through when the loca! station 
connects to a remote stat ion. 


The fol | ow ing steps take p | ace when a 
connection is estab | i shed. Initial {ys our 
station js in the “Disconnected” state. 
Our attempt to connect to another station 
(by tyring “CONN <«callsi¢n>") is 
interpreted by the FSM as 3n_ avents 3nd 
classified (e19) The FSM state transi t ion 
function is invoked», with Parameters 
current-state (which is “Iti sconnected”) » 
and event (which is e119). The function 
y ie lds a new state ("Link Estab !i shment ") » 
and an action (send 3 SABM packet to 
the addressed stat ion). The act ion is 
Performed and the system waits,» readyt o 
respond to my of the events wh ich may 
occur in the “L ink. Estat | i shment” state. 


From this’ simplified examele, it 
should be c lear that 3n FSM model is ideal 
for specification, ded i gn and 
implementation of 3n event dr i ven system, 
such 3s a Protocol. The advantages of 
adoption of the FSM mode! are discussed 
later. The rest of this section describes 
some jdeas on how FSMs can be imp lemented 
i n Fascaly arepresentative high level 
lansuade. 


DISC : DM 


CONN : SABM 


St 


Dis- 
connected 


DISC:UA 
RNR,RR,REJ, DISC, 


I with poll:DM pie 


SABM,RNR,RR,REJ, 
I with poll:DM 


Note: 


STOP: 


Disconnect: 
Kequest 
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CONN, DM, FRMR : 
SAB 
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Information 
Transter 


CONN: 
SaBM REJ,RR,I 
(with poll) sRR 
REJ, RR, I 
eenout poll) 


SABM: UA 


STOP :DIN 


CONN and STOP are operator commands for connecting and 


disconnecting to the remote station respectively. 
Al.1 other names are AX.25 frame types. 


AX.25 FSM ‘ ed | i e8 i e9 I I e146 {| e17 | i e199 |} 
EVENT {I withi ' SABM : DISC 3 : UA ? DM H : CONN ;: 
} Poll } feitherteither! ieitherteither: : cmd | 
STATE -=----------- ponn--- ee fee 4 pao ee oe 
1 Disconnected i DM i : UAsSS: DM i ; DM : DM H iSABM 1 S2 | 
2 Link. Setup io i ' UA,SS: IIMsS1: { = io: i H ss \ 
3 Frame Reject + FRMR i : UA,SSt UArSLi — H {SABM»S23 
4 Disconnect RastilM Sti + DOMsSii UALS i $1 : Sil H i SABM;S2} 
S Information XferiR R ; UA + UArS1i i= foo H ney 
Figure 1. Extract of the AX.25 FSM. 
FSM based Ime | ementat i on of AX. 25 const 
Si_Tisconnected=17 
Once the FSM mode 1} of the S2_LinkEstab li shment-2 > 
Protoco! is completely defined, ‘ 
imp jementat ion becomes stra i shtforward and AO_NoAction=0; 
somewhat, mechanical. The components to be Ai_SendSABM=1; 
defined are: . 
E1t.CONNcemd=1; 
i. the state table, E2_QDMr ece ived=2; 
ii. the state vari stb le,» nbr_istates =ny 
nbr_oevents =ns 
iii the acti on procedures, nor_actions=n? 
iv. the FSM procedure, type 
steate_type = 
Vv. the meintloor. Si_Disconnected..Sn_Statene 
event-type = 
Some examples of these follow. The EF1L_CONNcmd.. En EventNze 
Finite State Table (FST) can easi ly be action-type = 
defined: AO_NoAction. .An_ActionNye 
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var 
FSTiarrayli..nbrestates, 
1..nbrieventsliof 
record 
newstateistate_type; 
action tact ion-type 
end; 


The state varishle is simply defined: 


var current _stateistste_typea) 


event) pairin the 
In Pascal, this 


Each (newstate, 
FST must be initialised. 
becomes rather ted i ous: 


FSTCSi_Disconnected, 
E1_CONNcmd] .newstate t= 
S2_LinkEstablishment? 
FSTCS1_Dtisconnected», 
EL_CONNcmdd. 3ction t= 
Al_sendSABM> 


FSTCS2_LinkEstablishmants 
E2?_DiMreceived].newstatei= 
Si_Disconnecteds 
FSTCS2_LinkEstablishment»s 
El_OUMreceived].action i= 
AO NoAction; 


etc 


The stse transitionfunction canbe 
implementeds3as 3 simple Pascalfunction: 


function FSM(eventtevent_typre) istate_tupes 
{ globals: FST, current ustsete } 
besin 
case FSTCcurrent_state,s event], act i on of 
AO_NoAction: €donath ing} 
Al_sendSARM : bes in sendSABM ()7.., 7) ends 
A2_Action2 * begin € do Action 2 } end; 


An _ActionN tedin ¢€ do Action n } ends 
end {case}? 
FSM := 

FSTCcurrent state, eventi.newstate: 


end CFSM}; 


The 3ct i on procedures AO_NoOActi on... 
An_Act i ONNtake care of al | Processing 
needed to handle the event. These 
Procedures may call other ‘utility’ 
procedure5 to Jo lower level process ing. 


The maintoorpof the Process takes 
the fol lowing form: 


current-state :=initial-state; 
repeat 

get-event (event) # 

current_state i= FSM(event) » 
untilcurrent-state = terminal_state? 


178 


The Procedure “get_event (event) " 
monitorstoth the packet_ports andthe 
keyboard, for any input which canb e 
classified as 3n event: 


Procedure get event (var eventieventutypa) } 
var 
kbd buff eristringl1i..lonsgestucmd]> 
frame_buffertframe, 


event := no-event ; 
repest 
€wait for received frame or typed key } 
if Key Pressed then 
get char 
if charis 3 CR then 
analyse_cmd (kbd buffer sevent) 
else 
aprpendchart o kbd_buffer; 
else 
if frame rece i ved then 
analyse_frame(frame_buffersevent) 
unt i | event <> no_event? 


The comment "wait on 3 received frame 
or typedkey" refers to animplementation 


specific issue. | f both fram@eception 
and keyboard mon i tari ng is done by 
interrupt handlersrs Procedure’ get-event 
should unschedule itself eatthis Point. 


In animp lementat ion where interrupts are 
not available, the procedure can sime ly 
loop until 3 received frame is detected or 
akey i s pressed. 


Experience with [tesign Abstractions 


Exper ience has shown that adopt ion of 
these desi gn ahstract i ons has m3ny more 
advantages than dissdvantages. 


ObJect-based implementations of 
device interface software (such as_ the 
serial_port or packet port) offer all the 
advantages of modulari ty: 


i. Abstraction. Specific details of 
the Physical port device are 
hidden. 

ii. A well defined interface. Al | 


references to the device #0 through 
3 common i nterface. 


iii. Interface definitions can be 
application specific. The 
definition of the interfaceto the 
Port (ie, the access Procedures) is 
entirely UP to the programmer. 


iv, Isolation. Rerl acement or ursrading 
of the physical device canbe done 
transparent !lyto the rest of the 
software. 


A Possible disadvantage is the 
over head of structure. Using structure 
imposes the need for more object code 


anddsta,wh ich mayi n some Cases result 
in stower execution speed. This has not 
teen3 problem in both RTITY and AX.25 


software, but may cause problems athi sgher 
tsudretes. 


The edvantagesof adortingthe FSM 
model inimpe.1 ementati on were found to be: 


Centralisationo f Control. The 
entire ’control policy’o f the 
protocol is described neatly and 
simplyin 3 sinsletable. 


ii. Simplicity. A comp | icated protocol 
can become readshle end 
understandab le. 


iii. Enforcement of Structure. Useo f 
an FSM model enforces 3 uniform 
approachto the organisationof the 
entire Program. 


iv. Modiriability. Maintenenceo f 3 
Piece of software is made easier by 


the strict enforcement Of 
structure. Once the Finite State 
Table has teen set ups andthe 
set of action procedures”~ wri tten 
asdrivers for lower level “utility 
Procedures” » new actions, 


transitions and states can usually 
be addedavickly andeasily. 


The an fly di ssadvantase encountered was 
the Potent ialfor the F’SM model to become 
comp lex, When Protocols become 
complicated, their FSM model canbecome 
very large and cumbersome (this is c3lled 
“state explosion"). Tabular 
representationso f IlIarde FSMs can be 
managed, but gdrarhi calrepresentati ond may 
be .unwieldidy 


Conclusion 


The everase personal computer can 
host 3 perfectly satisfactory environment 
for communi cat i on sof tware deve lopment in 
3 hitghlevel lansuage. 


The use of 3 h ish fevel language 
requires 3 more formal sapproacht oO 
software design. Software for driving the 
10 devices canconvenientlr te ordanised 


as 3 module. In anevent driven system», 
the entire system’s control flow can be 
encersulated in 3 Finite State Machi ne 
mode |, 


These desi gn abstract i ons have teen 
eppliedin the development of softwarefor 
RTTY and AX. 25 by t h e author. They were 
foundt o increase software relisbilits, 
end make the source code more 
understandable andmodifisttie. 
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